Method, device and system for synchronizing of data providing for the handling of an interrupted synchronization process

ABSTRACT

The present invention provides a method, a network device and a system for allowing for resuming a preceding incomplete synchronization session is provided, wherein the preceding incomplete synchronization session has been interrupted during its performing. In principle the resuming of the preceding incomplete synchronization session is based on the following operations according to the inventive concept. A communication connection for synchronization of data between a first and a second device is establishing. The first and the second device comprise each a predefined set of data records to be synchronized. A first and a second update identifier are communicated between the first and the second device. The first update identifier specifies a preceding complete synchronization session having been performed between them and the second update identifier specifies a preceding incomplete synchronization session having been performed between them. Synchronization related information is exchanged between the first and the second device. The herein exchanged synchronization related information comprises that part of synchronization related information which has not been exchanged during the preceding incomplete synchronization session. Data in the first device and the second device is synchronized in accordance with the exchanged synchronization related information. The contents of the first update identifier is updated with the contents of the second update identifier.

BACKGROUND OF THE INVENTION

[0001] 1. Field of the Invention

[0002] The present invention relates to a method and a device,respectively, for synchronizing of data between a synchronizing clientdevice and a synchronizing server device and further to the respectivesynchronizing devices. More particular, the present invention relates toa method and a device for synchronizing of data, respectively, allowingfor improved handling of an interruption of an active synchronizationprocess.

[0003] 2. Description of Related Art

[0004] The synchronization of data is a well known concept or techniquefor users, respectively, having at least two different electronicdevices in use and processing the same kind of data with theseelectronic devices. In general, synchronization takes place between aterminal device (e.g., a mobile phone) and a server device (e.g., anapplication in a local PC or a dedicated synchronization server). Datafrom terminals, such as portable computers, PDA terminals (personaldigital assistant), mobile phones, mobile stations or pagers, can besynchronized with networked devices acting as synchronization serversbeing represented by networked applications, applications of desktopcomputers or with other managing applications of data stores oftelecommunications systems, wherein the term “data store” should beunderstood as broad as possible, i.e. shall cover arbitrary sets ofdata. In particular data of a calendar, data of contacts, data of e-mailapplications as well as data relating to device/application settings andconfigurations are typically synchronized.

[0005] Synchronization has been based on the use of differentmanufacturer-specific protocols which are incompatible. This restrictsthe use of terminal or data types and often causes troubles to the user.In mobile communication, in particular, it is important that data can beretrieved and updated regardless of the terminal and application used.

[0006] To improve synchronization of application data, a language knownand referred to as synchronization markup language SyncML has beendesigned, which is based on the extensible markup language (XML). Byusing a SyncML synchronization protocol, which employs messages in theSyncML format, data of any application can be synchronized betweennetworked terminals and a network server of any kind. The SyncMLsynchronization protocol works both in wireless and in fixed networksand supports several transmission protocols. The above presented SyncMLsynchronization technology addresses in particular the synchronizationof data stores or databases, respectively.

[0007] Conventionally, a synchronization of data records is performed ata distinct point in time in order to harmonize, i.e. to bring intocorrespondence, two distinct predefined sets of data records stored atdifferent storage places, i.e. at different synchronizing devicesmanaging and employing the storage places, resulting in two equivalentsets of data records at both storage places at this distinct point intime. The synchronization of data records performed at a distinct pointin time is further designated as a synchronization session. Thesynchronization of the sets of data records is obtained during such asynchronization session by exchanging information, instructions andcommands allowing both participating synchronizing devices for modifyingtheir stored sets of data records resulting in a harmonization of them,wherein such modification operations comprises adding of data, removingof data, appending data to current data, updating of data and the like.The exchange of required information and commands is for practicalpurposes carried out by communicating between the synchronizing devicesone or more messages each containing a distinct subset of the totalrequired information, instructions and commands necessary to perform theharmonizing at each synchronizing devices. Moreover, each of the one ormore messages is acknowledged in order to indicate successful operationin accordance with its message information contained therein.

[0008] Basically, synchronization processes as described above can behandled and performed in either a full synchronization process alsodesignated as slow synchronization or an incremental synchronizationprocess also designated as normal or fast synchronization, respectively.During a synchronization session performing a full or slowsynchronization process, respectively, all predefined sets of datarecords in both participating synchronizing devices are harmonized.During a synchronization session performing an incremental or fastsynchronization process, respectively, a point in time of the lastcompleted synchronization session is logged in both participatingsynchronizing devices and in case the logged point in time stored inboth synchronizing devices matches only data records being modifiedsince this logged point in time are selected for synchronization allother are excluded from the synchronization process. Therefore, a changelog may be maintained by the synchronizing devices logging themodification, adding or deleting point of time of data records.Alternatively, the modifications may be determined in another mannersuch as investigating the modification time stamps of the records, ifsuch exist. Both synchronization processes, i.e. the so-called slow andthe so-called fast (normal) synchronization are defined and used in theSyncML standard. Further types of synchronization processes areavailable and used but these further synchronization processes can bereduced to the aforementioned basic synchronization processes.

[0009] When a record and/or a group of records has been synchronizedwith the other database, an acknowledgement is sent back to the senderof the record. Two fundamental ways for handling the acknowledgementscan be implemented in synchronization applications. In the firstimplementation each successful synchronization of a data record or abatch of data records is acknowledged and logged by the synchronizingdevices preferably in such one or more change logs. In the secondimplementation the acknowledgements are handled at the end of asynchronization session, i.e. as soon as both synchronizing devicesindicate a proper closing of the synchronization session and thecorresponding employed communication connected. Further, the handling ofthe acknowledgements at the end of a synchronization session and theupdating of a point in time specifying the last completedsynchronization session is operated substantially at the same time. Incase the synchronization session is carried out in the way of a slowsynchronization process taking into account the point in time specifyingthe last completed synchronization session is obviously not required.

[0010] The first implementation primarily addresses synchronizationapplications used for synchronizing for example distributed databaseswith high-speed connection to each other in order to maintain and ensuredata integrity. In such implementations, the capacity requirements ofstoring and maintaining change logs for each data record, therequirement of processing capability for processing the change logs aswell as the requirement of network bandwidth for exchanging necessaryacknowledgements are of minor importance. In view of synchronizing datastored in small electronic device such as mobile phones, handhelds,personal digital assistants, communicators and the like the storagecapacity and processing power are limited such that storing, maintainingand processing of change logs for each data record is cumbersome,inefficient and sometimes not even possible. Moreover, the networktraffic resulting from the required acknowledgements is not acceptableas it is also expensive and time-intensive in mobile communicationenvironments.

[0011] The second implementation, wherein the updating of time stampsand handling the acknowledgements for the item is carried out at the endof the session, is suitable for use in small electronic devices andsupported by the SyncML standard. Nevertheless, this implementationraises the problem that an interruption of a currently performedsynchronization session is not provided for. The maintaining of thesynchronization information exchanged during a partially operatedsynchronization session is not possible since, the updating of the timestamps (synchronization anchors) and the handling of theacknowledgements at the end of the synchronization session is notachieved due to the interruption. Even if the acknowledgements of dataitems are handled during the session, since the time stamps are updatedonly at the end of the session, interruption of a slow synchronizationleads to loss of the already processed synchronization information. Inboth the above cases the synchronization session has to be repeatedcompletely in order to ensure data integrity. Depending on the amount ofsynchronization related information, i.e. depending on the number ofdata records to be synchronized, an even huge number of messages areexchanged during a single synchronization session normally comprisingseveral synchronization messages. For example 400 data records of 500data records may have been synchronized during a synchronization sessionand an interruption occurs. In the following synchronization session allof the 500 data records have to synchronized again independent ofwhether the synchronization is operated as either a fast or a slowsynchronization process.

SUMMARY OF THE INVENTION

[0012] The object of the invention is to provide a method allowing forresuming an interrupted synchronization session in order to avoid acomplete repetition of the interrupted synchronization session. Theprovision for resuming an interrupted synchronization session isconstructed such that neither high storage capacities, high processingpower, high number of interchanged acknowledgements nor highcommunication bandwidth are required. The method is suitable to beimplemented in a small electronic device in an economic way.

[0013] According to an embodiment of the invention, a method allowingfor resuming a preceding incomplete synchronization session is provided,wherein the preceding incomplete synchronization session has beeninterrupted during its operation. The resuming of the precedingincomplete synchronization session is achieved by the followingoperations.

[0014] A communication connection for synchronization of data between afirst device and a second device is established. The first device and asecond device comprise each a set of data records to be synchronized.Conventionally, data records are organized in a data storage or adatabase maintained by a corresponding application.

[0015] A first update identifier and a second identifier arecommunicated either from the first device to the second device or fromthe second device to the first device. The direction of transmissiondepends on what device indicates the resuming of the precedingincomplete synchronization session and the direction of thesynchronization. The indicating device transmits both identifiers to theother one. The first update identifier specifies a preceding completesynchronization session having been performed between the first deviceand the second device. The first update identifier has been stored inthe first device and the second device during an initialization of thepreceding complete synchronization session. More specifically, the valueof the identifier is stored, but the name or storage place of the valuemay vary according to the implementation. Commonly, the first updateidentifier is a time stamp used for logging the initiation time of thepreceding complete synchronization session. Alternatively, theidentifier can be any numerical value, for example a monotonicallyincreasing numeric integer string, a text string, or a mixture of these,created in an orderly fashion or at least to some degree or partrandomly. According to the invention, the second update identifierspecifies a preceding incomplete synchronization session having beenperformed between the first device and the second device. The secondupdate identifier has been stored in the first device and the seconddevice during an initialization of the preceding incompletesynchronization session. Commonly, the second update identifier isanalogously also a time stamp or such used for indicating the initiationtime of the preceding synchronization session that was interrupted.However, in the prior art, the behavior and use of the second updateidentifier is defined only during a synchronization session, but notafter an interruption or a completion of a session.

[0016] The method according to the present method has four steps forsynchronizing. A first step includes establishing a communicationconnection for synchronization of data between a first device and asecond device each comprising a set of data to be synchronized. A secondstep includes transmitting a first update identifier and a second updateidentifier, the first update identifier denoting a preceding completesynchronization event having been performed between the first device andthe second device, a value of the first update identifier having beenstored at least in the first device, the second update identifierdenoting a preceding incomplete synchronization event having beenstarted between the first device and the second device, a value of thesecond update identifier having been stored at least in the firstdevice. A third step includes retrieving or forming an indication ofdata that has been successfully synchronized during the precedingincomplete synchronization event. The first step includes using theindication, synchronizing data that has not been successfullysynchronized during the preceding incomplete synchronization event; and(4) at least in the first device, updating the value of the first updateidentifier with said value of the second update identifier.

[0017] The method may also include a step of transmitting additionalinformation relating to the preceding incomplete synchronization eventand comprising at least one information out of a group comprisinginformation about the preceding incomplete synchronization, andinformation about data successfully synchronized in accordance withreceived synchronization related information.

[0018] The method may also include a step that is performed in at leastone of the first device and the second device of comparing, in a firstcomparison, a value of the first update identifier transmitted from thefirst device with a value of the second update identifier of the firstdevice stored in the second device; and of comparing, in a secondcomparison, a value of the second update identifier transmitted from thefirst device with a value of the second update identifier of the firstdevice stored in the second device, as well as carrying out at least oneof the following options:

[0019] 1) In case the second comparison yields a value of true, afurther step of synchronizing data between the first device and thesecond device, the data comprising data that has not been exchangedduring the preceding incomplete synchronization event.

[0020] 2) In case the second comparison yields a value of false,synchronizing data between the first device and the second device, thedata comprising at least data that has been synchronized during thepreceding incomplete synchronization event.

[0021] 3) In case the first comparison yields a value of false, afurther step of synchronizing data between the first device and thesecond device, the data comprising data that has been synchronizedduring the preceding complete synchronization event.

[0022] 4) In case the first comparison yields a value of true, a furtherstep of synchronizing data between the first device and the seconddevice, the data that has not been synchronized during the precedingcomplete synchronization event.

[0023] The step of establishing a communication connection forsynchronization may include transmitting an initial message instructingat least one of the first device and the second device to prepare forresuming the preceding incomplete synchronization.

[0024] The synchronization may be based on a synchronization protocol inaccordance with the SyncML standard, the first update identifier being aLAST synchronization anchor. The second update identifier may be atleast one of a NEXT synchronization anchor and a PAUSE synchronizationanchor. Moreover, the additional information relating to the precedingincomplete synchronization event may include at least one informationout of a group of a synchronization event session identifier (sessionID), a synchronization message identifier (message ID), and one or moreidentifiers of acknowledged data and their respective data store.Moreover still, the additional information has been stored at least inthe first device before transmitting the first and second updateidentifiers.

[0025] In the method, data has been successfully synchronized if theacknowledgement for the data or the message containing the data has beensuccessfully received, and the acknowledgement indicates either apositive or a negative status of the synchronization of the data or themessage.

[0026] The invention also provides a software tool for synchronizing,comprising program portions for carrying out the steps of theaforementioned method, wherein the software tool is for beingimplemented in a computer program for being executed on a processingdevice, a terminal device, a communication terminal device or a networkdevice, as well as a computer program or computer program product forsynchronizing the same.

[0027] The invention also provides a device for use in a network andcapable of synchronizing data having a storage medium, a communicationinterface, a retrieving or a forming component and an updatingcomponent. The storage medium has predefined sets of data to besynchronized. The communication interface establishes a communicationconnection for synchronization of data to another device for use in anetwork, for communicating a first update identifier and a second updateidentifier with the other network device and for exchanging data withthe other network device. The first update identifier denotes apreceding complete synchronization event having been performed with theother network device, the first update identifier having been stored atleast in the network device. The second update identifier denotes apreceding incomplete synchronization event, the second update identifierhaving been stored at least in the network device, wherein the datacomprises at least data that has not been synchronized during thepreceding incomplete synchronization event. The retrieving or a formingcomponent retrieves or forms an indication of data that has beensynchronized during the preceding incomplete synchronization event, theindication having been stored in the network device. The synchronizingcomponent synchronizes data in accordance with the indication. Theupdating component updates contents of the first update identifierstored with contents of the second update identifier stored.

[0028] The communication interface may be adapted for transmittingsupplementary additional information relating to the precedingincomplete synchronization event. The additional information may includeat least one information out of a group comprising information about thepreceding incomplete synchronization, information about a lastsuccessful exchange of synchronization related information andinformation about data successfully synchronized in accordance withreceived synchronization related information.

[0029] The device may also include a component for comparing, such that,in a first comparison a value of the first update identifier transmittedfrom the device with a value of the second update identifier of thedevice stored in the other device, and, in a second comparison, a valueof the second update identifier transmitted from the first device with avalue of the second update identifier of the device stored in the otherdevice. The component for carrying out at least one of theaforementioned options discussed above in relation to the method.

[0030] The invention also provides a system for synchronizing,comprising a first network device and a second network device, whereineach device includes elements for performing steps similar to thatdiscussed above in relation to the overall method and device of theinvention.

BRIEF DESCRIPTION OF THE DRAWINGS

[0031] It invention will be described in greater detail by means ofembodiments with reference to the accompanying drawings, in which

[0032]FIG. 1 shows a schematic diagram illustrating a set of exemplaryelectronic devices between which synchronization of information isoperable;

[0033]FIG. 2 shows a chronological sequence diagram of a synchronizationprocess comprising several messages exchanged between a synchronizingclient device and a synchronizing server device according to anembodiment of the invention;

[0034]FIG. 3a shows a chronological sequence diagram of asynchronization process analogously to FIG. 2 and being interrupted orstopped according to an embodiment of the invention;

[0035]FIG. 3b shows a chronological sequence diagram of asynchronization process resuming the interrupted or stoppedsynchronization process of FIG. 3a according to an embodiment of theinvention;

[0036]FIG. 4 shows an excerpt of a XML-coded synchronization message inaccordance with the synchronization process illustrated in FIG. 3b andaccording to an embodiment of the invention; and

[0037]FIG. 5 shows a schematic block diagram illustrating componentscomprised by a synchronizing client device and a synchronizing serverdevice according to an embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

[0038] In the following, the embodiments of the invention will bedescribed in the view of a system supporting the SyncML synchronizationstandard without limiting the invention thereto. Information relating tothe SyncML standard can be obtained from the SyncML Initiative providingpublicly the full standard documentation. Same or equal parts,components and/or operations shown in the figures will be referred tousing the same reference numerals.

[0039]FIG. 1 shows a schematic diagram illustrating a set of exemplaryelectronic devices between which synchronization of information isoperable. A certain data store content of for example a mobile terminalshall be harmonized with data store content provided by designateddevices for example offering a central storage of this data storecontent to be accessible by means of several different mobile and/orstationary terminals. Conventionally, mobile terminals act assynchronization clients harmonizing or synchronizing data relating tocertain predefined applications running on these synchronization clientswith the contents of a data store or several data stores provided bydedicated server devices centrally storing the application related data.FIG. 1 illustrates a plurality of possible client devices and serverdevices operable with the synchronization operation. Typically, clientdevices are mobile stations like mobile phones 17 or personal digitalassistants (PDA), mobile computers like notebooks 15, electronic devicesstoring digital data like digital cameras 16 as well as stationaryterminals like desktop computers (PC). Further, dedicatedsynchronization server devices may be stationary terminals like desktopcomputers 10, dedicated network servers 11 e.g. operating theirsynchronization capability as networked synchronization applications oreven mobile computers like notebooks 12 e.g. running synchronizationserver applications. It shall be noted that the client devicefunctionality is not limited to mobile terminals as described abovealthough the presented concept of synchronization is described in viewof mobile terminals connected to dedicated serving devices.

[0040] A corresponding synchronization process in accordance with theSyncML protocol standard is established via an appropriate logicalcommunication connection. The logical communication connection isprovided by any communication networks in combination with transportprotocols to which the synchronization protocol is adapted. A suitablecommunication network may be a local area network (LAN) or a wide areanetwork (WAN) which may comprise the internet and an intranet of acompany but also wire-based serial networks such as universal serial bus(USB) or standardized serial communication (e.g. RS-232). Theparticipating synchronization devices may be also connected via awireless communication network such as a mobile network supportingglobal system for mobile communication (GSM) services and/or supportinggeneral packet radio services (GPRS), a third generation mobilecommunication network such as a universal mobile telecommunicationsystem (UMTS) network, a wireless local area network (WLAN), short rangeradio communication network, such as a Bluetooth network, wireless localloop (WLL) or an infrared network (IrDA). The logical communicationconnection between the participating synchronization devices may beprovided by a single communication network of the aforementioned typebut also may be provided by several communication networks of theaforementioned types interconnected by dedicated network routing devicesinterconnecting communication networks connections and, if necessary,translating between data protocols of the respective employedcommunication networks.

[0041] With respect to the SyncML protocol, standard the SyncMLsynchronization protocol, and hence also with respect to the SyncMLdevice management protocol standard, the SyncML device managementprotocol is implemented on the top of appropriate protocols inaccordance with the type of employed communication network. Appropriateprotocols on which top the SyncML synchronization protocol can beimplemented are the hyper text transfer protocol (HTTP), the wirelesssession protocol (WSP) of the wireless application protocol (WAP)standard, the object exchange protocol (OBEX) used for cableconnections, such as universal serial bus (USB) or RS-232, forshort-range radio frequency connections (Bluetooth) or for infraredconnections (IrDA), the transport control protocol/internet protocol(TCP/IP) stack and on top of the transport layer service which isoffered by the e-mail protocol (e.g. simple mail transfer protocol,SMTP).

[0042] Transfer at the lower layer can be performed according to theunderlying network using e.g. short messages SMS (short message service)or other signaling type transmission methods (e.g. USSD; unstructuredsupplementary service data), circuit-switched data calls,packet-switched data transfer services as well as paging messageservice, messages provided via cell broadcast and the like.

[0043] In the following the term data store shall be understood as broadas possible, i.e. shall cover arbitrary set(s) of data provided by datastorage(s) to be accessed. In particular, the sets of data relate tospecific applications and may be organized to meet application specificrequirements such as data of calendar applications, directoryapplications, contact applications (e.g. vcard applications), e-mailapplications and the like. Further, the arbitrary set(s) of data can beorganized in one or more databases including data records providing datato be accessed. Further the term data store shall be understood ascovering network data services or networked service(s), respectively,i.e. as covering arbitrary set(s) of data provided by networkedservice(s) to be accessed similar to data store(s). Conventionally,networks services are based on data stores having a specific servicerelated data store content.

[0044] The following sequence diagrams depict operational sequencesaccording to embodiments of the methods of the present invention. Thedepicted sequences of operations are just illustrative and not limitingthereto. Further realizations based on similar or related operationalsequences are also possible.

[0045]FIG. 2 shows a chronological sequence diagram of a synchronizationprocess comprising several messages exchanged between a synchronizingclient device and a synchronizing server device according to anembodiment of the invention.

[0046] SyncML synchronization session are conceptually bounded into socalled SyncML packages. The SyncML packages is simply a conceptualframework for one or more SyncML messages that are physically exchangedbetween the synchronizing devices and that are required to convey a setof synchronization information and commands. Not all SyncML packages areinvolved in any of the types of synchronization provided by the SyncMLstandard. The exact number of the SyncML messages depends on the amountof information to be conveyed.

[0047] A coarse overview of the SyncML packages is described in thefollowing list. A detailed description can be obtained from the SyncMLstandard documents.

[0048] Package 0—initiation of the synchronization message. A clientdevice can receive unsolicited messages, so-called “notifications” or“alerts”, instructing to cause the receiving device to establish a backconnecting for initiating a synchronization session. Note that anidentical effect to receiving a notification can be caused in otherways.

[0049] Package 1—initialization from client device to server device. Oneor more initialization messages are transmitted for example comprising:client device information (device identifier etc.), client deviceproperties, client authentication, type of synchronization,identifications of databases of which data records are to besynchronized, stored LAST anchor, new NEXT anchor, etc.

[0050] Package 2—initialization from server device to client device. Oneor more initialization messages are transmitted for example comprising:server device information (device identifier etc.), server deviceproperties, server authentication, response and status information aboutinformation comprised in one or more client initialization messages.

[0051] Packages 1 and 2 are part of the initialization phase. Thefollowing packages 3 to 6 are part of the synchronization phase of thesynchronization message.

[0052] Package 3—Client to server synchronization. One or more clientsynchronization messages are transmitted for example comprising: clientdata modifications, i.e. any changes to the data of the client databasesidentified in the synchronization initialization, etc. In the case of afast synchronization process, only data records that have been modifiedsince the previous synchronization session (LAST anchor) are reported,in the case of a slow synchronization process all data records arereported.

[0053] Package 4—Server to client synchronization. One or more serversynchronization messages are transmitted for example comprising:information about the server's analysis of transmitted client datamodifications, and also server data modifications, i.e. any changes tothe data of the server databases identified in the synchronizationinitialization, etc. In the case of a fast synchronization process, onlydata records that have been modified since the previous synchronizationsession (LAST anchor) are reported, in the case of a slowsynchronization process all data records are reported.

[0054] Package 5—Data update status, map operation. One or more dataupdate status messages are transmitted for example comprisinginformation about the results of data update (synchronization due toserver modifications), map operations (table) for mapping local uniqueidentifier (LUID) and global unique identifier (GUID), etc. A localunique identifier is an identifier assigned to a data record and beinglocally unique on the client side, i.e. per device and application. Thelocal unique identifier allows for identifying a data record. A globalunique identifier is an identifier assigned to a data record and beinglocally unique on the server side.

[0055] Package 6—Map acknowledgement. One or more map acknowledgementmessages are transmitted for example comprising acknowledgementsinforming the client device of receiving one or more data update statusmessages by the server, etc.

[0056] A client message in accordance with package 3 may cause a serverresponse message in accordance with package 4 and vice verse dependingon the synchronization information and commands contained in the clientmessage or the server message, respectively.

[0057] Each message of a synchronization message contains a sessionidentifier (session ID) such that the messages can be associated to adistinct synchronization session. Each message contains a messageidentifier (message ID) such that misalignments of exchanged messages atthe client device and at the server device is prevented, respectively.Further, each last message of each package type contains a finalindicator to indicate that this is the last one.

[0058] The synchronization process is further distinguished by what kindof information (which data records) is to be synchronized (a slow or afast synchronization, i.e. total number of data records or onlymodifications since a distinct point in time), in which device(s) (ineither the client device or the server device or in both devices)synchronization is performed and from which device synchronization isinitiated. The type of synchronization can be e.g. two-way sync, slowsync, one-way sync from client only, refresh sync from client only,one-way sync from server only, refresh sync from server only and serveralerted sync.

[0059] The designations of the enumerated types of synchronizationitself describe the synchronization process and are easilyunderstandable. A more detailed description reference is made to theSyncML standard documentation.

[0060] By way of example, the chronological sequence diagram and thesynchronization process shown in Fig.2 are based on a fast two-waysynchronization type, respectively, although the scope of the inventionis intended to include other synchronization types. A client 100synchronizes with the server 110. In accordance with the abovedescription of the package sequence, the depicted synchronizationsession consists of an initialization phase 210 followed by thesynchronization phase each comprising several synchronization messages.All synchronization messages contain a same session ID (not depicted).

[0061] During the initialization phase 210 of the client 100 and server110, both devices exchange device information (device identifiers etc.),device properties, device authentication information. The client 100further defines the type of synchronization (herein fast two-waysynchronization type) and reports the LAST anchor stored and a NEXTanchor newly defined to the server 110. The server 110 compares the LASTanchor transmitted by the client 100 with a corresponding value storedin the server 110 stored and conforms the LAST anchor and the NEXTanchor if the stored and received LAST anchors match to allow for fastsynchronizing. The state (content) of the NEXT anchor is undefined (bythe prior art, i.e. the prior art two-way synchronization process doesnot provide any particular value for it) in the server 110 (indicated bythe “?” sign) up to the moment the client 100 transmits this newlydefined one. If the anchors do not match, slow synchronization isalerted to the client 100. The information exchange during theinitialization phase 210 is illustrated by a first operation 200referring to an client initialization message corresponding to a package1 message and a second operation 201 referring to an serverinitialization message corresponding to a package 2 message. Bothmessages referred to by operations 200 and 201, respectively, containthe same message ID 1.

[0062] After completion of the initialization phase 210, the client 100prepares the synchronization 211, i.e. identifies the data recordsmodified in accordance with the received LAST anchor. A clientsynchronization message (package 3 message type) referred to byoperation 203 contains a first batch of client modifications, hereinfive modifications of a total of ten identified modifications. It may benoted that client modifications include commands and/or data content.The commands comprise above all an add, update, delete, etc. which arecompleted with data content to synchronize a respective data record.Additionally, this message further contains status information inaccordance with the previous server initialization message. The server110 receives this first client synchronization message, analyzes thereceived client modifications, solves possible conflicts emerging fromthe client modifications and processes the client modifications(operation 212). A corresponding server synchronization message (package4 message type) referred to by operation 204 is transmitted to theclient containing client modification acknowledgements and statusinformation of the analyze and synchronization processing. Both theclient synchronization message referred to by operation 203 and theserver synchronization message referred to by operation 204 areidentifiable by a common message ID, herein message ID 2. It should benoted, however, that the message numbering may deviate from what hasbeen presented above. Indeed, the only purpose to be served by themessage numbering is that each device has a consistent view of themessage numbers, i.e., the numbering towards the client and the serverdo not even have to match.

[0063] A following client synchronization message (package 3 messagetype) referred to by an operation 206 contains a second batch of clientmodifications, herein remaining five modifications of ten totalidentified modifications. This client synchronization message containsadditionally a final indicator indicating that this is the last clientsynchronization message containing client modifications. The server 110receives this last client synchronization message, analyzes the receivedclient modifications, solves possible conflicts emerging from the clientmodifications, processes the client modifications and due to the finalindicator prepares (identified under consideration of the server's LASTanchor) server modifications to be transmitted to the client 100(operation 212). A corresponding server synchronization message (package4 message type) referred to by an operation 207 is transmitted to theclient containing server modifications, client modificationacknowledgements and status information of the analyze andsynchronization processing. In accordance with the synchronizationsession depicted in FIG. 2, a single server synchronization message issufficient for transmitting all identified server modifications to theclient such that this message additionally contains a final indicator.In an operation 214 the client 100 processes the received servermodifications. Both messages referred to by operations 206 and 207,respectively, contain the same message ID 3.

[0064] A client update status message (package 5 message type) referredto by operation 208 is subsequently conveyed to the server 110containing acknowledge information and synchronization statusinformation due to the server modifications and if necessary mapoperations to the server 110 processing the data record map tableassigning local unique identifiers and global unique identifiers.Finally and not depicted the client update status message may beresponded by the server 110 with one or more map acknowledgementmessages (package 6 message type).

[0065] Conclusively, the synchronization session and the communicationconnection through which the synchronization messages of this sessionare communicated are closed. In the case where no error is detectedregarding the finalizing of the synchronization session and thecommunication connection, the content of the NEXT anchor defined at thebeginning of the synchronization session stored. This assignment isperformed at the client 100 in an operation 215 and at the server in anoperation 216 (in fact, the server may not call the anchor LAST, butnevertheless, the value stored to the anchor is the value of the NEXTanchor sent by the client). Thus a following fast synchronizationprocess is possible.

[0066] It is noted that the defining of the NEXT anchor at the beginningof a synchronization session and the assigning of the NEXT anchorcontent to the LAST anchor after a proper finalization of thesynchronization session prevent conflicts due to modification of datarecords on the client side or server side during the synchronizationprocess. It may be additionally remarked that the content of thedepicted LAST anchors and NEXT anchors are just to enlighten theirusage. For practical purposes the LAST anchors and the NEXT anchors arenormally composed of or derived from a date value and a time value, orthey are numerical values of other kind. This kind of composing mayensure to generate an unambiguous LAST and NEXT anchors, respectively.

[0067]FIG. 3a shows a chronological sequence diagram of asynchronization process analogously to FIG. 2 and being interrupted orstopped according to an embodiment of the invention. The synchronizationsession depicted in FIG. 3a shall be identical to this one presentedwith reference to FIG. 2, i.e. the initial conditions, the operations200-204 and the operations 210-212 are performed in the same way.Correspondingly, the operations depicted in FIG. 3a and the respectiveoperations depicted in FIG. 2 and common with FIG. 3a are referenced bythe same reference numerals.

[0068] In FIG. 3a the initialization phase and the correspondinginitialization messages of the client 100 and the server 110 areomitted. The operation 203 referring to the first client synchronizationmessage (package 3 type) containing the first 5 of 10 clientmodifications and the operation 204 referring to the first serversynchronization message (package 4 message type) is shown containingstatus information corresponding to the client modifications.

[0069] In an operation 205 the synchronization is interrupted orstopped. An interruption or stop can be caused due to several reasons,for example the synchronization session is stopped on user interaction,on user initiative, on power loss of the client 100 or server 110 e.g.due to lack of battery or accumulator capacity, on loss of thecommunication connection e.g. due to loss of coverage in radiocommunication networks, due to interference in the communicationconnections only to present a selection of possible reasons.

[0070] In order to allow for resuming the synchronization sessionaccording to an embodiment of the inventive method the client 100 andthe server 110 log information relating to the incompletesynchronization session. This information allowing for resuming theincomplete synchronization session comprises at least the LAST anchorand NEXT anchor at least in the client 100 which are logged in both theclient 100 and the server 110. Further, this information can alsocomprise a session ID of the incomplete synchronization session, amessage ID of the last message properly transmitted and for which theclient 100 has received an acknowledgement, and one or more unique datarecord identifiers, i.e. local unique identifiers or global uniqueidentifiers of data records according to those modifications have beingtransmitted and transmissions of those have being acknowledged duringthe incomplete synchronization session.

[0071] Alternatively instead of employing the NEXT anchor for loggingthe point in time at which the incomplete synchronization session hasbeen started a new anchor, e.g. a PAUSE anchor, is defined and employedespecially to be used for resuming an incomplete synchronizationsession. In the following the inventive concept is described withreference to the NEXT anchor but not limiting the inventive conceptthereto. To adapt the description following below to such a new PAUSEanchor the term NEXT anchor is simply to be replaced by the term PAUSEanchor.

[0072]FIG. 3b shows a chronological sequence diagram of asynchronization session carrying on the interrupted or stoppedincomplete synchronization session of FIG. 3a according to an embodimentof the invention.

[0073] The resuming synchronization session is initiated by an operation250 referring to a new initialization message (package 1 type)comprising an alert command indicating the intend of the client 100 tothe server 110 so as to resume the previous incomplete synchronizationsession described above with reference to FIG. 3a. This newinitialization message contains at least the LAST anchor and the NEXTanchor which have been logged in accordance with the interruption of theprevious incomplete synchronization session (operation 205 in FIG. 3a).The server receives these LAST anchor and the NEXT anchor from theclient and compares them with those LAST anchor and the NEXT anchorlogged by itself. It shall be noted that in comparison to thesynchronization session presented in FIG. 2 and its analogy presented inFIG. 3a the NEXT anchor has a well defined state and content on theserver side, respectively.

[0074] At least one of the client 100 and/or the server 110 may eithercommand, initiate or carry out any one of the following four differentoptions depending on whether either the LAST anchors match and/orwhether the NEXT anchors match, as follows:

[0075] 1) In case the received and the logged LAST anchors and thereceived and the logged NEXT anchors match, the server 110 confirms theresuming of the incomplete synchronization session (resuming fastsynchronization) by transmitting a server initialization message(package 2 type) referring to operation 251 and containing at least theLAST anchor and NEXT anchor for acknowledgement. The confirmation forallowing for resuming may be based additionally on further informationrelating to the incomplete synchronization session to be resumed (referto operation 205 in FIG. 3a). For example, the aforementioned loggedsession ID of the incomplete synchronization session and/or logged amessage ID of the last message properly transmitted are consulted duringthe examination operation of the logged anchors.

[0076] 2) In case the received and the logged LAST anchors match but thereceived and the logged NEXT anchors do not match, a (normal) fastsynchronization session in the kind of that presented with reference toFIG. 2 is commanded by the server. The mismatching NEXT anchors preventthe resuming of the incomplete synchronization session described withreference to FIG. 3a.

[0077] 3) In case the received and the logged LAST anchors do not matchbut the received and the logged NEXT anchors match, a resuming slowsynchronization session is commanded by the server. This resuming slowsynchronization session is not depicted in Fig. 3 b. In short, theresuming slow synchronization session exchanges synchronization relatedinformation which allow to synchronize all data records predefined forbeing synchronized. But this synchronization related information isexcluded from the resuming slow synchronization session which has beensuccessfully exchanged and synchronized during the incompletesynchronization session shown in FIG. 3a.

[0078] 4) In case both the received and the logged LAST anchors and thereceived and the logged NEXT anchors do not match, neither a resumingfast synchronization session nor a resuming slow synchronization sessioncan be initiated. Also a fast synchronization is not possible. Acomplete slow synchronization session (as aforementioned; not shown inFIG. 3b) comprising the exchange of all data records predefined forbeing synchronized has to be performed in order to establish a propersynchronization state between both participating devices.

[0079] The following description is based on the assumption that firstcase (the received and the logged LAST anchors as well as the receivedand the logged NEXT anchors match) is correct. This case is alsoindicated in the FIG. 3b having an illustrating of the state (value) ofthe logged LAST and NEXT anchors of both the client 100 and the server110. The server 110 transmits a server initialization message (package 2type) referring to operation 251 and containing at least the LAST anchorand NEXT anchor for acknowledgement.

[0080] As described with respect to operation 205 shown in FIG. 3afurther log information relating to the incomplete synchronizationsession are logged at their interruption. As aforementioned thisinformation may comprise at least one of a session ID of the incompletesynchronization session, a message ID of the last message properlytransmitted and one or more unique data record identifiers, i.e. localunique identifiers or global unique identifiers of data recordsaccording to those modifications have being transmitted andtransmissions of those have being acknowledged during the incompletesynchronization session. It shall be noted that the information providedby local unique identifiers may not be sufficient and data baseidentifiers may have to be logged supplementary to the local uniqueidentifiers. The combination of a local unique identifier and theassociated data base identifier enables to determine (unambiguously) acorresponding data record referenced by the local unique identifier. Thedata base identifiers may be uniform resource locators (URI) as known inthe art.

[0081] The stored LAST anchor, the stored NEXT anchor and the storedinformation relating to the incomplete synchronization session allow forrestoring (re-establishing) the state of the previous incompletesynchronization session at the moment of interruption. This kind ofreconstruction allows now for generating the messages referred to by theoperations 206-208 shown in FIG. 2, illustrating a completesynchronization session, and missing in FIG. 3a, illustrating the samesynchronization session but incomplete due to the interruption after thetransmission of the synchronization message referred to by operation 204(FIG. 2 and FIG. 3a).

[0082] Both the new client initialization message and the serverinitialization message referred to by operations 250 and 251 comprisealso information necessary for establishing a synchronization sessionsuch as described with reference to operations 200 and 201 shown in FIG.2.

[0083] Herein, it is assumed that the conditions for resuming theincomplete synchronization session are satisfied and the incompletesynchronization session has been reconstructed which enables the client100 to carry on according to an embodiment of the method of theinvention. The client synchronization message (package 3 type) referredto by operation 252 corresponds to the second client synchronizationmessage referred to by operation 206 illustrated in FIG. 2. The clientsynchronization message comprises accordingly the last 5 of 10modifications and the final instructor to indicate that this message isthe last client synchronization message of the current synchronizationsession. Moreover, the message numbering, i.e. the message ID, isadapted to the current resuming synchronization session and thereforethe client synchronization message in FIG. 3b has a message ID 2subsequent to the previous message ID 1 of the initialization messages(referred to by operating 250 and operation 251). (It is important tonote that the scope of the invention is intended to include other typesof message numbering sessions.) The server 110 response to the clientsynchronization device by transmitting a server synchronization message(package 3 type) referred to by operation 253, corresponding to thesecond client synchronization message referred to by operation 206illustrated in FIG. 2. This server synchronization message containsserver modifications, client modification acknowledgements and statusinformation of the analyze and synchronization processing. In accordancewith the synchronization session depicted in FIG. 2, a single serversynchronization message is sufficient for transmitting all identifiedthe server modifications to the client such that this messageadditionally contains a final indicator. Both messages referred to byoperations 252 and 253, respectively, contain the same message ID 2.

[0084] A client update status message (package 5 message type) referredto by an operation 254 is subsequently conveyed to the server 110containing acknowledge information and synchronization statusinformation due to the server modifications and if necessary mapoperations to the server 110 processing the data record map tableassigning local unique identifiers and global unique identifiers. Thisclient update status message corresponds also and accordingly to theclient update status message referred to by the operation 208 describedwith reference to FIG. 2. Finally, although not depicted, the clientupdate status message may be responded to by the server 110 with one ormore map acknowledgement messages (package 6 message type).

[0085] Conclusively, the synchronization session and the communicationconnection through which the synchronization messages of this sessionare communicated are ended. In case no error is detected regarding thefinalizing of the synchronization session and the communicationconnection the content NEXT anchor defined at the beginning of thesynchronization session is assigned to the LAST anchor. This assignmentis performed at the client 100 in an operation 260 and at the server 110in an operation 261. Thus a following fast synchronization process isoperable. It is noted that the defining of the NEXT anchor at thebeginning of a synchronization session and the assigning of the NEXTanchor content to the LAST anchor after a proper finalization of thesynchronization session prevent conflicts due to modification of datarecords on the client side or server side during the synchronizationprocess. It may be additionally remarked that the content the depictedLAST anchors and NEXT anchors are just to enlighten their usage. Forpractical purposes the LAST anchors and the NEXT anchors are normallycomposed of or derived from a date value and a time value. This kind ofcomposing may ensure to generate an unambiguous LAST and NEXT anchors,respectively.

[0086] It shall be further noted that modifications on data recordsafter an incomplete synchronization session and before a resumingsynchronization session are not taken into account during the resumingof the incomplete synchronization session. The resuming synchronizationsession establishes a state of the data records or data storescomprising them as if the incomplete synchronization session had beencompleted successfully. For that reason, the NEXT anchor representing atime stamp of a synchronization session is not updated during aninitialization of a resuming synchronization session. The modificationsoccurred after an incomplete synchronization session can be synchronizedby initiating a synchronization session after a successful resumingsynchronization session, especially, a fast synchronization session canbe initiated since the LAST anchor stored in the client 100 and theserver 110 are updated and valid.

[0087] The acknowledgements that have been described in the context ofthe embodiments of the invention are to be interpreted to be any kind ofresponses to data received from the other end, including either apositive or a negative status of the synchronization of the data or themessage. Typically, an acknowledgement would confirm the updating of arecord, but an acknowledgement may also carry information of anunsuccessful operation, e.g., caused by a non-found record.Nevertheless, the handling of such errors is not an issue of theinvention, but it is left up to the implementation to take care of theerrors somehow. However, the occurrence of errors should not interferewith the resumption of the session, that is, the session should resumeat the first unacknowledged data item irrespective of whether there havebeen errors in the data items before it.

[0088]FIG. 4 shows an excerpt of a XML-coded synchronization message inaccordance with the synchronization process illustrated in FIG. 3b andaccording to an embodiment of the invention.

[0089] To insure an easy and interoperable implementation theindustry-standard extensible markup language (XML) has been selected forspecifying the synchronization messages that synchronize deices andapplications (using either plain text or the wireless binary XML, binarytechnique employed by wireless application protocol). SyncML has beendesigned within the memory capacity of all common mobile devices both instatic code and run-time execution space. Especially the binary codedextensible markup language (WBXML) is generally used for coding data toreduce the memory required to store messages and to reduce the resourcesneeded to process and to convey this data.

[0090] The SyncML contains a set of well-defined messages (as shownabove) being represented as XML documents or as multipurpose internetmail extension (MIME) entities. The representation specificationspecifies an XML document type description (DTD) which allow therepresentation of all information requires to perform synchronizationincluding data, metadata and commands. The synchronization specificationspecifies the SyncML messages that conform to the DTD in order to allowa SyncML client and SyncML server to exchange additions, deletion,updates and other status information.

[0091] Other DTDs define the representation of information on the device(such as memory capacity) and of various types of meta-information (suchas security credentials). The SyncML messages are conceptually based ona container concept as defined by the representation protocol. The eachSyncML messages contains a SyncML header section and a SyncML bodysection. The SyncML header contains routing, session, authentication andmessage information, whereas the SyncML body section contains variouswell-defined synchronization data comprising status information andsynchronization commands, each forming a sub-container.

[0092] The XML-based coding presented in FIG. 4 is an excerpt of anexample plain text coding of a SyncML message in accordance with theclient synchronization message referred to by operation 252 describedwith reference to FIG. 3b. The depicted XML-based coding contains theSyncML header section extending from line 3 to line 9 and the SyncMLbody section extending from line 10 to line 57.

[0093] Line 1 and line 2 contain common information on the XML-codingemployed and the character encoding used for textual representation andthe SyncML versioning information.

[0094] Each SyncML header contains a document type definition versioninginformation (VerDTD, line 4), a SyncML protocol versioning information(VerProto, line 5), a session identifier (SessionID, line 6) validduring one synchronization session to assign unambiguous all belongingsynchronization messages thereto and a message identifier (MsgID, line7) being increased such that each receiving synchronizing devicereceives subsequently synchronization messages having increasing messageidentifier numerals. The aforementioned elements of the SyncML headerdescribed as example, further optional and obligator elements arecontained in the SyncML header.

[0095] The SyncML body contains several logical and independentsubsection. A first status information subsection extends from line 11to line 19. This first status information subsection relates to thereference addressing of the data records to be synchronized. Inparticular, the target reference (TargetRef, line 16) defines aninternational mobile equipment identifier (IMEI) for addressing theclient, in this case a cellular communication device, whereas the sourcereference (SourceRef, line 17) defines a uniform resource identifier(URI) for addressing the server, in this case a networked server deviceaccessible via HTTP (hypertext transfer protocol). Further addressing ofindividual data records and data storage is based on this referenceaddress information. An arbitrary number of further status informationsubsection can also be comprised which is indicated by the second statusinformation subsection extending from line 20 to line 22. For exampleacknowledgments are coded as status information.

[0096] The SyncML body section contains further a synchronizationsubsection which is further subdivided. As example, a client indicatedmodification concerning an addition of an contact is comprised. Line 26contains the relative addressing path of the contacts database of theclient whereas line 29 contains the relative addressing path of thecontacts database of the server. The relative addressing paths arerelative to the reference addressing described above. The Metasubsection extending from line 31 to line 36 contains additionalmeta-information about the data record (the contact) to be added to thecontact database in the server. The subsection extending form line 37 toline 51 contains the adding instruction and the corresponding contactdata content. In line 40 the data format of the content data in line 46to line 48 is defined as x-vcard meta-type, whereas the correspondingdata contents is contented in line 46 to line 48. A local uniqueidentifier (LUID) used for uniquely referencing this contact in theclient is comprised in line 44. An arbitrary number of furthersynchronization information subsection can further be comprised which isindicated by an further synchronization information subsection extendingfrom line 52 to line 54.

[0097] The comprised Final instruction in line 56 indicates to theserver that this example client synchronization message is the lastmessage containing client modifications to be reported to the server forsynchronizing.

[0098] The aforementioned method for resuming an preceding incompletesynchronization session according to an embodiment of the invention canbe implemented in a client device and a server device in various ways.The following implementation is an example implementation being based ona SyncML standard implementation in which components have an enhancedfunctionality and capability in order to be additionally adapted tooperate in accordance with an embodiment of the invention.

[0099]FIG. 5 shows a schematic block diagram illustrating componentscomprised by a synchronizing client device and a synchronizing serverdevice according to an embodiment of the invention. FIG. 5 depicts aserver 110 representing a network device offering a networkedsynchronization service. The networked synchronization service isrepresented by one or more server applications 112 and correspondingassociated one or more data storage components 111. One or more serverapplications 112 provide the data synchronization with otherapplications being represented by one or more client applications 102 ofthe client 100 being a networked device. The one or more data storagecomponents 111 host data records for handling by the one or more serverapplications 112 and hence for synchronization with the client, whereinthe one or more data storage components 111 are for example one orseveral databases. The server 110 and the client 100 are connected overa communication network transport. A selection of suitable communicationnetworks for connecting client 100 and server 110 has been presented anddiscussed with reference to FIG. 1.

[0100] The one or more server applications 112 uses a datasynchronization protocol implemented as a synchronization server engine113 being a component of or a process on the server 110. The datasynchronization protocol is manifested on the communication network byclient applications accessing the provided synchronization servernetwork service and resources, respectively. A synchronization serveragent 115 interfaces and manages the access and the communication of thesynchronization server engine 113 to the network and enablescommunication of data synchronization operations with the client 100 andthe one or more client applications 102, respectively. Thesynchronization agent 115 performs the interfacing and communicating byinvolving a synchronization interface 116 and a synchronization adapter117, wherein the synchronization interface 116 is for example anapplication program interface (API) to the synchronization adapter 117.The synchronization adapter 117 is a component of or a process on theserver 110, respectively, which communicates conceptually with acounterpart synchronization adapter 107 on the client side. Thesynchronization adapter 117 is above all responsible for establishingand maintaining network communication connections between server 110 andclient 100, i.e. between the one or more server applications 112providing data synchronization service and the one or more clientapplications 102 accessing and employing this data synchronizationservice.

[0101] On the client side, the one or more client applications 102 withone or more associated data storage components 101 storing data recordsto be accessible by the one or more client applications 102 use asynchronization client agent 105, the synchronization interface 106 andthe synchronization adapter 107 to access the provided serversynchronization service. The synchronization client agent 105 enablescommunication of data synchronization operations with the server 110 andthe one or more server applications 112, respectively. Thesynchronization interface 106 represents for example analogously anapplication program interface (API) to the synchronization adapter 107.

[0102] The aforementioned method according to an embodiment of theinvention is included in the above presented conceptual componentframework of the server 110 and the client 100 for example byimplementing one or several code sections in the synchronization clientagent 115 and the synchronization server agent 105, wherein the one orseveral code sections comprise instructions which at execution of themperform an embodiment of the method for resuming an incompletesynchronization session. This way of implementation ensures that in caseof an interruption of a synchronization session required information forresuming this interrupted synchronization session are logged or storedin the client 100 and the server 110.

[0103] It will be obvious for those skilled in the art that as thetechnology advances, the inventive concept can be implemented in adifferent and broader number of ways. The invention and its embodimentsare thus not limited to the examples described above but may vary withinthe scope of the claims.

What is claimed is:
 1. Method for synchronizing, comprising:establishing a communication connection for synchronization of databetween a first device and a second device each comprising a set of datato be synchronized; transmitting a first update identifier and a secondupdate identifier, said first update identifier denoting a precedingcomplete synchronization event having been performed between said firstdevice and said second device, a value of said first update identifierhaving been stored at least in said first device, said second updateidentifier denoting a preceding incomplete synchronization event havingbeen started between said first device and said second device, a valueof said second update identifier having been stored at least in saidfirst device; retrieving or forming an indication of data that has beensuccessfully synchronized during said preceding incompletesynchronization event; using said indication, synchronizing data thathas not been successfully synchronized during said preceding incompletesynchronization event; and at least in said first device, updating saidvalue of said first update identifier with said value of said secondupdate identifier.
 2. Method according to claim 1, wherein the methodfurther comprises: transmitting additional information relating to saidpreceding incomplete synchronization event and comprising at least oneinformation out of a group comprising information about said precedingincomplete synchronization, and information about data successfullysynchronized in accordance with received synchronization relatedinformation.
 3. Method according to claim 1, further comprising: in atleast one of said first device and said second device: in a firstcomparison, comparing a value of said first update identifiertransmitted from the first device with a value of the second updateidentifier of the first device stored in the second device; in a secondcomparison, comparing a value of said second update identifiertransmitted from the first device with a value of the second updateidentifier of the first device stored in the second device; carrying outat least one of the following options: in case said second comparisonyields a value of true, synchronizing data between said first device andsaid second device, said data comprising data that has not beenexchanged during said preceding incomplete synchronization event; incase said second comparison yields a value of false, synchronizing databetween said first device and said second device, said data comprisingat least data that has been synchronized during said precedingincomplete synchronization event; in case said first comparison yields avalue of false, synchronizing data between said first device and saidsecond device, said data comprising data that has been synchronizedduring said preceding complete synchronization event; and in case saidfirst comparison yields a value of true: synchronizing data between saidfirst device and said second device, said data that has not beensynchronized during said preceding complete synchronization event. 4.Method according to claim 1, wherein establishing a communicationconnection for synchronization further comprises: transmitting aninitial message instructing at least one of said first device and saidsecond device to prepare for resuming said preceding incompletesynchronization.
 5. Method according to claim 1, wherein saidsynchronization is based on a synchronization protocol in accordancewith the SyncML standard, said first update identifier being a LASTsynchronization anchor.
 6. Method according to claim 5, wherein saidsecond update identifier is at least one of a NEXT synchronizationanchor and a PAUSE synchronization anchor.
 7. Method according to claim5, wherein said additional information relating to said precedingincomplete synchronization event comprises at least one information outof a group of a synchronization event session identifier (session ID), asynchronization message identifier (message ID), and one or moreidentifiers of acknowledged data and their respective data store. 8.Method according to claim 7, wherein said additional information hasbeen stored at least in said first device before transmitting said firstand second update identifiers.
 9. Method according to claim 1, whereindata has been successfully synchronized if the acknowledgement for thedata or the message containing the data has been successfully received,wherein the acknowledgement indicates either a positive or a negativestatus of the synchronization of the data or the message.
 10. Softwaretool for synchronizing, comprising program portions for carrying out theoperations of the method of claim 1, wherein said software tool is forbeing implemented in a computer program for being executed on aprocessing device, a terminal device, a communication terminal device ora network device.
 11. Computer program for synchronizing, comprisingprogram code sections for carrying out the operations of the method ofclaim 1, wherein said computer program is for being executed on aprocessing device, a terminal device, a communication terminal device ora network device.
 12. Computer program product for synchronizing, saidcomputer program product comprising program code sections stored on acomputer readable medium for carrying out the method of the method ofclaim 1, wherein said computer program product is for being executed ona processing device, a terminal device, a communication terminal deviceor a network device.
 13. A device for use in a network and capable ofsynchronizing data, comprising: a storage medium comprising predefinedsets of data to be synchronized; a communication interface forestablishing a communication connection for synchronization of data toanother device for use in a network, for communicating a first updateidentifier and a second update identifier with said other network deviceand for exchanging data with said other network device, wherein saidfirst update identifier denotes a preceding complete synchronizationevent having been performed with said other network device, said firstupdate identifier having been stored at least in said network device,said second update identifier denoting a preceding incompletesynchronization event, said second update identifier having been storedat least in said network device, wherein said data comprises at leastdata that has not been synchronized during said preceding incompletesynchronization event; a retrieving or a forming component forretrieving or forming an indication of data that has been synchronizedduring said preceding incomplete synchronization event, said indicationhaving been stored in said network device; a synchronizing component forsynchronizing of data in accordance with said indication; and anupdating component for updating contents of said first update identifierstored with contents of said second update identifier stored.
 14. Adevice according to claim 12, wherein said communication interface isadapted for transmitting supplementary additional information relatingto said preceding incomplete synchronization event, wherein saidadditional information comprises at least one information out of a groupcomprising information about said preceding incomplete synchronization,information about a last successful exchange of synchronization relatedinformation and information about data successfully synchronized inaccordance with received synchronization related information.
 15. Adevice according to claim 13, further comprising: a component forcomparing, in a first comparison, a value of said first updateidentifier transmitted from the device with a value of the second updateidentifier of the device stored in the other device, and for comparing,in a second comparison, a value of said second update identifiertransmitted from the first device with a value of the second updateidentifier of the device stored in the other device, said component forcarrying out at least one of the following options: in case said secondcomparison yields a value of true, synchronizing data between saiddevice and said other device, said data comprising data that has notbeen exchanged during said preceding incomplete synchronization event;in case said second comparison yields a value of false, synchronizingdata between said device and said other device, said data comprising atleast data that has been synchronized during said preceding incompletesynchronization event; in case said first comparison yields a value offalse, synchronizing data between said device and said other device,said data comprising data that has been synchronized during saidpreceding complete synchronization event; and in case said firstcomparison yields a value of true: synchronizing data between saiddevice and said other device, said data that has not been synchronizedduring said preceding complete synchronization event.
 16. System forsynchronizing, comprising a first network device and a second networkdevice, wherein said first network device comprises: a storage mediumcomprising predefined set of data to be synchronized; a communicationinterface for establishing a communication connection forsynchronization of data to said second network device for use in anetwork, for communicating a first update identifier and a second updateidentifier to said second network device and for exchanging data withsaid second network device; a retrieving or a forming component forretrieving or forming an indication of data that has been synchronizedduring said preceding incomplete synchronization event, said indicationhaving been stored in said first network device; a synchronizingcomponent for synchronizing of data in accordance with said indication;and an updating component for updating contents of said first updateidentifier stored with contents of said second update identifier stored;wherein said second network device comprises: a storage mediumcomprising predefined set of data to be synchronized; a communicationinterface for establishing a communication connection forsynchronization of data to said first network device for use in anetwork, for communicating a first update identifier and a second updateidentifier to said first network device and for exchanging data withsaid first network device, said second update identifier and said secondupdate identifier being stored, a synchronizing component forsynchronizing of data in accordance with said indication; an updatingcomponent for updating contents of said first update identifier storedwith contents of said second update identifier stored; and a componentfor comparing, in a first comparison, a value of said first updateidentifier transmitted from said first network device with a value ofsaid first update identifier stored in said second network device, andfor comparing, in a second comparison, a value of said second updateidentifier transmitted from said first network device with a value ofsaid second update identifier stored in the second network device;wherein said first update identifier denotes a preceding completesynchronization event having been performed with said second networkdevice, said first update identifier having been stored at least in onenetwork device, said second update identifier denoting a precedingincomplete synchronization event having been performed with said secondnetwork device, said second update identifier having been stored atleast in one network device; and wherein said data comprises at leastdata that has not been synchronized during said preceding incompletesynchronization event in case that said comparing yields the sameidentifiers, said exchanged information being based on said indication.